Transport multiplexer management and control

ABSTRACT

A feature-rich transport multiplexer and a number of associated methods, systems, subsystems, software features, graphical user interfaces and control systems are disclosed. The disclosure includes GUI&#39;s that enable operators to easily monitor and manipulate content streams flowing through a transport multiplexer in real-time. The disclosed interfaces include screens that supply operators with identity, structure, configuration, bandwidth utilization and/or status information for system hardware and software. The disclosed features also provide computer assisted routing configuration for present and future routing events through simple manipulation, such as drag and drop operations, of graphical objects. Routing control is further simplified by permitting operators to configure routing control of individual content stream components as well as groups of such components simultaneously. Further flexibility is permitted by predetermination of future routing events, thereby enabling the automatic execution of configuration changes at a future time. Various types of content, such as video, audio, IP data can be manipulated to achieve various results such as one or more multiplexed MPEG data streams.

CROSS REFERENCE TO RELATED CASES

[0001] This application claims the benefit under 35 U.S.C. 119(e) ofco-pending U.S. Provisional Application Nos. 60/285,188 filed Apr. 20,2001 and entitled “Broadband Bandwidth Management, Device Management andMulti-Media Control System”; and No. 60/285,153 filed Apr. 20, 2001 andentitled “Data Insertion, Transport, Grooming, Aliasing, Routing, andMultiplexing of MPEG 2 Data Streams”, which Provisional Applications arehereby incorporated by reference.

[0002] This application is related to co-pending U.S. Patent applicationSer. No. ______ filed Apr. 16, 2002 (based on provisional applicationNo. 60/322,063 filed Sep. 13, 2001) and entitled “High Speed Serial DataTransport Between Communications Hardware Modules,” which Application ishereby incorporated by reference.

REFERENCE TO COMPUTER PROGRAM

[0003] This application hereby incorporates by reference a computerprogram listing submitted concurrently herewith on two duplicate compactdiscs pursuant to the provisions of 37 C.F.R. § 1.52(e)(5). One completecopy of the computer program listing is provided on each of theaccompanying compact discs and the discs have been labeled “Copy 1” and“Copy 2” as required by 37 C.F.R. § 1.52(e)(5). The incorporatedcomputer program listing is contained in a single file created on Apr.12, 2002, named “mib tables-appendix.doc” and consisting of 150kilobytes.

BACKGROUND OF THE INVENTION

[0004] 1. Field of the Invention

[0005] The present invention is directed to systems, processes,methodologies, apparatus and related software to manage and controlbroadband communications hardware. More particularly, the inventionrelates to improved up management and control of content streams routedthrough a broadband media router. Accordingly, the general objects ofthe invention are to provide novel systems, methods, apparatus andsoftware of such character.

[0006] 2. Description of the Related Art

[0007] Broadband media convergence between video, audio and data inrecent years has created a chaotic environment of different standardsand legacy communications technologies. Nonetheless, the relationshipbetween physical and logical resources in such systems needs to bemanipulated and communicated between broadband hardware, its controlsystem and its operators. This has, in the past, been accomplished witha complex of dedicated management and control computers, each of whichwas responsible for administration of a specific piece of communicationshardware. While modern communications hardware personnel, such as cableoperators and television programmers, have used such systems in thepast, such systems use great numbers of diverse equipment to control thesystem. These control systems have been centrally located in closeproximity to each other and to the communications hardware beingmanaged. For these and other reasons, conventional solutions to the needfor control and management of broadband communications hardware haveproven to be cumbersome, inflexible, inefficient and expensive topurchase and operate.

[0008] An additional problem with conventional broadband communicationshardware is their inability to conveniently provide operators withinformation regarding the system hardware and software. This createsmany inefficiencies in operation of such equipment. For example,troubleshooting system errors is currently a difficult and expensiveprocess because system operators must physically inspect the broadbandcommunications hardware in order to determine the system hardwareutilized and its operational status. In particular, troubleshootingsystem difficulties may entail operator inspections of a communicationshardware rack to determine if all of the communications hardware hasbeen plugged-in, turned on, connected to the desire content streamsand/or operated in a particular way.

[0009] There is, accordingly, a need in the art for novel methods,systems and apparatus that enable communications hardware personnel,such as cable operators and television programmers, to manage andcontrol complete broadband media router systems with a single computer.Such methods and apparatus should be capable of remotely monitoring andcontrolling such systems over a network. Ideally, control would beachieved with java-based system that could be uploaded to a remotepersonal computer using a browser during a set-up phase and subsequentlyrun on the remote computer as a java program. In order to providemaximum flexibility at minimal cost, such a system would communicate viathe network using a common browser and a widely recognizedcommunications protocol such as SNMP.

[0010] There is a further a need in the art for novel methods, systemsand apparatus that can provide operators with information regardingsystem hardware and software. Such methods and apparatus facilitatetroubleshooting of system errors by avoiding the need to physicallyinspect broadband communications hardware in order to determine thesystem hardware utilized and its operational status. Indeed, suchmethods and apparatus of managing and controlling communicationshardware should be capable of providing highly stable control overbroadband media routers so that such troubleshooting can be minimized,if not eliminated altogether.

SUMMARY OF THE INVENTION

[0011] The present invention satisfies the above-stated needs andovercomes the above-stated and other deficiencies of the related art byproviding methods, systems and apparatus that enable communicationshardware personnel to manage and control complete broadband media routersystems with a single computer. Such methods and apparatus in accordancewith the invention are capable of remotely monitoring and controllingsuch systems over a communications network such as an Ethernet network.Management of a broadband media router, is preferably achieved with ajava-based system that has been uploaded to a remote personal computervia the network during a set-up phase and then run on the remotecomputer in order to remotely manage the hardware. To provide maximumflexibility at minimal cost, the invention communicates via the networkin accordance with a robust, flexible and widely recognizedcommunications protocol such as SNMP.

[0012] Other aspects of the invention are directed to particularlystable methods of controlling certain aspects of normal systemoperations (such as enabling a port) to thereby minimize, if notentirely eliminate system instability and, by extension, system failureand troubleshooting. The invention achieves this result by practicingstable hardware enable and disable sequences.

[0013] In the event that system failure does occur for some reason, theinvention facilitates troubleshooting of system errors by avoiding theneed to physically inspect the managed hardware in order to identify thevarious hardware utilized, to determine their connectivity and todetermine the operational status of each component. This advantageobtained through the use of system hardware and software identity,configuration and status viewing capabilities enabled by informationretrieval via the network. The invention also provides an extensivearray of log messaging features that further facilitate systemtroubleshooting and monitoring.

[0014] Naturally, the above-described methods of the invention areparticularly well adapted for use with the above-described apparatus ofthe invention. Similarly, the apparatus of the invention are well suitedto perform the inventive methods described above.

[0015] Numerous other advantages and features of the present inventionwill become apparent to those of ordinary skill in the art from thefollowing detailed description of the preferred embodiments, from theclaims and from the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The preferred embodiments of the present invention willhereinafter be described in conjunction with the appended drawingfigures, wherein like numerals denote like elements, and wherein:

[0017]FIG. 1a illustrates the hardware architecture of a transportmultiplexer in accordance with one preferred embodiment of the presentinvention;

[0018]FIG. 1b illustrates a preferred form of the firmware hostprocessor architecture of the transport multiplexer of FIG. 1a;

[0019]FIG. 2 illustrates system initialization and resource discoveryprocesses for the transport multiplexer of FIG. 1, the processes beingin accordance with one preferred embodiment of the present invention;

[0020]FIG. 3 illustrates various system hardware attribute viewingcapabilities in accordance with one preferred embodiment of the presentinvention;

[0021]FIG. 4 illustrates system attribute viewing capabilities inaccordance with one preferred embodiment of the present invention;

[0022]FIG. 5 illustrates various output port enabling processes inaccordance with one preferred embodiment of the present invention;

[0023]FIG. 6 illustrates specification of present video and/or audiostream routing event(s) in accordance with one preferred embodiment ofthe present invention;

[0024]FIG. 7 illustrates various system bandwidth utilization viewingcapabilities in accordance with one preferred embodiment of the presentinvention;

[0025]FIG. 8 illustrates certain event logging and viewing capabilitiesand processes in accordance with one preferred embodiment of the presentinvention;

[0026]FIG. 9 illustrates specification of future content stream routingevent(s) in accordance with one preferred embodiment of the presentinvention;

[0027]FIG. 10 illustrates various IP data encapsulation and insertioncapabilities in accordance with one preferred embodiment of the presentinvention; and

[0028]FIG. 11 is a detailed flow chart illustrating the IP dataencapsulation and insertion capabilities of FIG. 10 in greater detail.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0029] The ensuing detailed description provides preferred exemplaryembodiments only, and is not intended to limit the scope, applicability,or configuration of the invention. Rather, the ensuing detaileddescription of the preferred exemplary embodiments will provide thoseskilled in the art with an enabling description for implementing apreferred exemplary embodiment of the invention. It being understoodthat various changes may be made in the functional arrangement ofelements without departing from the spirit and scope of the invention asset forth in the appended claims.

[0030] As shown in FIGS. 1a and 1 b, TMX 20 includes a plurality ofhardware, firmware and software components. FIG. 1a is a hardwarearchitecture diagram showing a representative transport multiplexer(TMX) 20 in accordance with one preferred embodiment of the presentinvention. As shown therein, the transport multiplexer can include, forexample, a computer 22′ (with an element manager 22 and a GUI 80) thatis communicatively linked to a TMX chassis 42 via a network 24. TMXchassis 42 preferably includes a host processor board 40′ (preferablywith a VxWorks operating system), an input processor board 50′, andoutput processor board 55′, a multiplexer board 60′ and a transcodingboard 70′. These components are preferably, but not necessarilycommunicatively linked to one another with a single TMX chassis 42. Thebasic physical model of the preferred TMX chassis hardware is asfollows: the TMX chassis is a container for boards, each board is acontainer for ports and processors, each processor is a container forfirmware, and each port is a container for a protocol hierarchy (i.e.,DS3, MPEG, TCP/IP, etc.). The chassis and each board have a set of stateand status variables associated with them. These include: 1) anadministrative state which is used to synchronize configuration accessof multiple managers; 2) an operational state which is used to indicatewhether or not the TMX (or a component of it) is in a fully enabled andoperational state; and 3) an alarm status which is used to signal avariety of alarm conditions by the TMX or a component thereof. Asdescribed in detail below, the host processor 40 controls the varioushardware and software components of TMX 20 and stores MIB table data inaccordance with SNMP for use by the various other components of the TMXand the element manager.

[0031] Transport multiplexer 20 is suited to a wide variety ofapplication environments including: (1) cable headend; (2) satelliteuplink; and (3) terrestrial broadcast. Communication between elementmanager 22 and TMX chassis 42 is preferably performed in accordance witha modified Simple Network Management Protocol (SNMP) and the contentstreams to be routed through transport multiplexer 20 are preferably inaccordance with one of the well-known MPEG standards. Most preferably,the content streams are MPEG2 data streams. While some preferredembodiments of the present invention use some conventional MIB tables inaccordance with well known SNMP standards, many of the MIB's referencedherein comprise novel data structures. These data structures are fullydefined in the computer program appendix incorporated by reference.Therefore, those of ordinary skill will more than amply understand thenature and function of those novel data structures based on theteachings contained herein.

[0032] A more detailed description of the hardware components of TMX 20is provided in previously mentioned co-pending U.S. Patent application,Ser. No. ______, filed Apr. 16, 2002 and entitled “High Speed SerialData Transport Between Communications Hardware Modules,” whichApplication has been incorporated herein by reference. Accordingly,further detailed discussion of these hardware components is notnecessary, a complete understanding of these components being achievedwith reference to these incorporated applications.

[0033] The relationship between physical and logical resources in thesystem needs to be manipulated and communicated between TMX chassis 42,element manager 22 and human operators 10 (e.g., FIG. 2). This isgenerally achieved by modeling the various hardware components of thesystem. The TMX modeling elements are integrated into the SNMPManagement Information Base (MIBs) by using the standard “MIB 2”interfaces table (ifTable) to represent each one of the modelingelements as an interface with specific extensions as specified below.This permits identification of any board and/or any port, by its tableindex: the ifindex in the ifTable.

[0034] With continuing reference to FIG. 1a, element manager 22 ispreferably linked to TMX chassis 42 by an Ethernet. It will beappreciated by those skilled in the art that other network technologiescan alternatively be used. Element manager 22 may be uploaded as ajava-application from TMX 42 to a remote computer using a browser, theremote computer preferably being communicatively linked to transportmultiplexer 20 via network 24 during an initial set-up phase.Subsequently, element manager 22 can be run on the remote computer as ajava program. The remote computer is preferably a conventional personalcomputer with a conventional operating system and browser, the systempermitting control over TMX chassis 42 subsequent to installation ofelement manager 22. A graphical user interface (GUI) is preferablyincorporated into element manager 22 and is described in detail below.The GUI is preferably presented to an operator on a conventionalpersonal computer monitor (e.g., an LCD screen or a CRT monitor). A widevariety of alternative software and hardware components for hosting andoperating graphical user interface and element manager 22 will readilyoccur to those of ordinary skill in the art based on the disclosurecontained herein

[0035]FIG. 1b illustrates various firmware and software components 52-69of TMX 20 which are communicatively linked to one another as showntherein. These components include an SNMP agent 44, a message handler 45and a fault manager 59. TMX 20 further comprises a resource manager 52,a configuration manager 46, a PAT/PMT collection module 54, a PSIPcollection module 57, an input module 50, an IP encapsulation module 66,a time table manager 67 and a number of DSP API's. These includemultiplexer processing 60, transcode processing 62 and quantizationlevel processing 64. There is a one-to-one correspondence between thesefirmware modules and certain hardware components of the preferredembodiment. The corresponding hardware components can be found in FIG.1a and include input processor board 50′, multiplexer board 60′ (with amultiplex processor 60 and a quantization level processor 61), atranscoding board 70′ (with either 5 transcode processors 71 or 3transcode processors, 1 multiplex processor and 1 QLP 71′).Consequently, when the configuration manager performs operations on thefirmware modules, the corresponding hardware modules are also affected.The flow of information and commands between the various componentswithin TMX chassis 42 is generally indicated in FIGS. 1a and 1 b by theuse of arrows. In particular, the flow of commands and information fromelement manager 22 is through SNMP agent 44, which translates SNMPprotocol commands from element manager 22 into a conventional form sothat they can be understood by the various other components of TMX 20.The preferred conventional communication protocol is a simple protocolin which a number indicative of a request or command is passed alongwith an associated data structure for receiving data to be manipulatedin accordance with the associated command. Thus, SNMP agent 44 generallyacts as a communication broker between element manager 22 and the hostprocessor firmware. SNMP agent 44 allows SNMP based management of andcontrol over firmware functionality such as grooming, splicing, datainsertion, etc., because it provides an interface with the variousfirmware modules (e.g., input processing task 50, multiplexer processing60, transcode processing 62 and quantization level processing 64) thatultimately provide the desired functionality.

[0036] Configuration manager 46 receives commands and information fromSNMP agent 44 via MIB message handler 45 and determines how to utilizethe hardware and other firmware to execute those commands at the cardlevel. A detailed understanding of the various other components of TMX20 will be obtained with reference to FIGS. 2 through 9 and thecorresponding detailed description of these figures in the remainder ofthis specification.

[0037]FIGS. 2 through 11 illustrate the nine primary operational aspectsof transport multiplexer 20. These nine operational aspects include (1)initialization and discovery of system resources 100; (2) view systemhardware attributes 134; (3) view system software attributes 156; (4)enable output port 166; (5) specify present video and/or audio routingevent(s) 184; (6) view bandwidth utilization 206; (7) view log activity222; (8) specify future routing event(s) 238; and (9) IP dataencapsulation and insertion 260. These aspects of the present inventionare discussed in detail immediately below.

[0038] With reference to FIG. 2, there is illustrated therein systeminitialization and resource discovery processes for the broadbandmultiplexer of FIG. 1, the processes being in accordance with onepreferred embodiment of the present invention. As shown, initializationand discovery of the inventive system commences with power-up 101 of TMXchassis 42, whereupon resource manager 52 conducts discovery (at 102) ofthe hardware and system software information. Thus, TMX chassis 42executes a number of functions at 104 to identify system componentsinstalled in TMX chassis 42. Also at 102, MIB message handler 45populates the appropriate MIB's (ifTable and ifStack) with informationand SNMP agent 44 awaits queries at 106. Upon completion of these tasks,TMX chassis 42 is prepared to execute various activities based onoperator-driven commands delivered to TMX chassis 42 via element manager22.

[0039] At this point, an operator 10 can start up element manager 22 inresponse to which the element manager, at 104, displays graphical userinterface 80 showing a blank tree view screen 81 for viewing. Blank treeview screen 81 includes an input tree window 82, an output tree window82′ and a log message window 87. At 108, element manager 22automatically reads the appropriate MIB's to discover the hardware thatis currently installed in TMX 20. This includes system hardwareattribute data such as port data and/or physical structure. There areseveral types of ports ( e.g., ASI, DHEI, SMPTE 310, DS3) which aresupported by the preferred embodiment of the present invention. Data forvarious port parameters is described /defined by the ifentry MIB table.At 110, element manager 22 downloads the appropriate DSP code to theIdentxTable MIB. SNMP agent 44 of TMX chassis 42 creates a new MIB entryat 112 and message handler 45 passes this information to configurationmanager 46 for fulfillment. At this point, element manager 22 requestsPAT data at 114. This request is processed by the TMX at 116. At 120,the PAT is parsed by element manager 22 so that the appropriate PMT'scan be identified. These are requested at 122 and this request isprocessed by the TMX at 124. After the requested information isgenerated, SNMP agent 44, awaits further queries at 126. This data isthen read by element manager 22 at 128 and graphical user interface 80is updated. In particular, the requested data is used to populate treeview screen 81 with system hardware icons 84 and 84′ and, preferablymnemonic, hardware names 83 and 83′ extracted from the data streamsthemselves using PSIP collection module 57. Operator 10 is, thus,presented with a visual representation of the system hardwarecomponents.

[0040] After receiving the system hardware attributes data from TMXchassis 42, element manager 22 proceeds to retrieve and display logmessages that may have been generated at 130. This is achieved with theassistance of a fault manager 59 and SNMP agent 44 at 132. Thus, oncelog polling has commenced, element manager 22 displays the port and logdata at 132 to graphical user interface 80 where the tree view screen isupdated to display input ports 85, output ports 85′ and log messages 88in log message window 87. As shown, input and output ports 85 and 85′preferably have associated mnemonic and alphanumeric identifiers. Theports are also preferably color coded to indicate whether or not theports are active. Upon reviewing the newly completed tree view screen81, operator 10 can initiate various activities as described below withrespect to FIGS. 3 through 10. These activities can include, forexample, view system hardware attributes 134, view system softwareattributes 156, enable output port 166, specify present video and/oraudio routing events 184, view bandwidth utilization 206, view logactivity 222, specify future routing events 238 and IP dataencapsulation and insertion event(s) 260. Various other relatedactivities that can be performed by operator 10 will readily occur tothose of ordinary skill in the art based on the disclosure containedherein.

[0041] Turning now to FIG. 3, this Figure illustrates various systemhardware attribute viewing processes 134 in accordance with onepreferred embodiment of the present invention. The hardware processesshown in FIG. 3 are initiated by operator 10 upon selection of thechassis view screen from the menu items at the top of tree view screen81. This option is accessed by selecting the “view” menu item at the topof the screen and selecting the chassis view option. Available hardwareviewing options include “front chassis view” and “rear chassis view” and“system information.” Upon selection of one of the chassis view optionsat the graphical user interface, element manager 22 gathers therequested hardware information from the appropriate MIB's (136) with theassistance of TMX chassis 42. This MIB data is provided by TMX chassis42 as indicated by 138 and element manager 22 then displays theinformation on one of chassis view screen 89 and 90.

[0042] With continuing reference to FIG. 3, one can see that graphicaluser interface 80 uses the received hardware and status data to displaysystem hardware attributes and, in particular, chassis view screens 89and 90 as initially requested by operator 10. Front chassis view screen89 includes various graphical objects indicative of the identity of,physical structure of, configuration of and status of the various cardsreceived within TMX chassis 42. In this illustrative example, thesecards include CPU card 40″, multiplexer card 60″, first input processorboard 50″ and second input processor board 50′″. While it is alsopossible to receive log messages within log message window 87 of frontchassis view screen 89, no log messages have been generated in thisillustrative example.

[0043] Rear chassis view screen 90 can also be selected by operator 10as an alternative to front chassis view screen 89. In this illustrativeexample, rear chassis view screen 90 includes various graphical objectsindicative of the identity of, physical structure of, configuration ofand status of the rear portion of the various cards received within TMXchassis 42 and discussed above with respect to the front chassis view.The log messages can, optionally, also be displayed in log messagewindow 87 of rear chassis view screen 90. This aspect of the presentinvention allows an operator 10 to easily select, and then, view systemhardware attributes in the manner discussed above. This feature of thepresent invention is particularly advantageous in that it allows anoperator to troubleshoot difficulties with transport multiplexer 20without having to physically access the communications hardware itself.

[0044] The preferred continuous hardware status polling features of thepresent invention are shown at 139. In particular, the LED statusinformation provided in the chassis view screens is updated at regularintervals by the repeated execution of the functions shown in blocks140-146.

[0045] Turing now to FIG. 4, this figure illustrates system attributeviewing processes and capabilities 156 in accordance with one preferredembodiment of the present invention. As shown therein, viewing of systemattributes such as board type, DSP attributes, software version, etc.commences with the initial system discovery process when the TMXexecutes the functions shown at 158. Thus, this information is readilyavailable for display and SNMP agent 160 waits for such queries at 160.Upon selection of the version view menu option within the top portion oftree view screen 81 by operator 10, element manager 22 gathers therequested information at 162 displays it in system attributes screen 91.The data can then be viewed by operator 10 as desired. As shown in FIG.4 and Table 1 below, system attributes data displayed on screen 91preferably includes the following data fields for the board and softwarerunning on each chassis slot: TABLE 1 Board Name TMX Application JVMVersion System Name IP Address Chassis ID Board Revision FPGA VersionVxWorks 08 CPU Version MAP Lib Version MUX Version QLP Version TPEVersion

[0046] In the illustrative embodiment of FIG. 4, TMX chassis 42 is amid-plane TMX chassis with five board slots in each half of the chassis.Accordingly, this illustrative example includes ten slots (five slotsfor each half-plane). A detailed description of the structure andoperation of TMX chassis 42 is contained in the application incorporatedby reference and a wide variety of variant arrangements will readilyoccur to those of skill in the art based on the disclosure containedherein.

[0047] As shown in FIGS. 3 and 4, the preferred embodiment of thepresent system includes a GUI with a system information tab with whichan operator can access information about the system such as system name,system description, system up-time and system location. This feature ofpresent invention operates in a manner that is generally analogous tothe view software version feature shown in FIG. 4 and described inconnection therewith immediately above

[0048]FIG. 5 illustrates various output port enabling capabilities inaccordance with one preferred embodiment of the present invention. Asshown therein, output port enabling is initiated upon selection byoperator 10 of the particular port to be enabled. Upon selection of aport, element manager 22, at 168, displays the transport editor 92 withdefault values. Operator 10 can then view the default data and edit thedata if desired, such as by changing the status from disabled toenabled. For example, an operator will typically enable a transportstream, name that stream and assign an information transfer bit rate forthe selected port. Upon selection of the “OK” button, the transporteditor is closed, and element manager 22 gathers transport informationfrom the editor and places it in the appropriate MIB tables (see 170).The TMX chassis also uses this information to execute the enable requestas indicated at 172. The MIB table could be either one of two types:TMXiftable (for most ports) or the TMXgiexttable (for DS3 ports) due tothe varying information requirements of the different port types.

[0049] Further, element manager 22 creates a PAT at 174 and the PAT isoutput by the TMX as indicated at 176. Finally, the tree view screen 81of the GUI is updated by the element manager as indicated at 178.Graphical user interface 80 indicates successful enablement of thedesired port by changing the attributes of the port icons in tree viewscreen 81. This is preferably accomplished by changing the color of theport icons, but other alternatives (such as changes in shape, movement,location, size, sound, etc.) will readily occur to those of ordinaryskill in the art. Operator 10 can, thus, visually confirm that portenablement was successfully completed by viewing the newly-updatedgraphical user interface 80.

[0050]FIG. 6 illustrates various system-assisted video and/or audiorouting capabilities in accordance with one preferred embodiment of thepresent invention. As described in greater detail below, the presentinvention enables operator 10 to define and execute content streamrouting either manually or semi-automatically. In particular, thepreferred embodiment of the present invention provides operators withthe ability to manually enter routing data element by element or,alternatively, to drag and drop graphical objects to and from variouslocations of the tree view screen 81. Element manager 22 cooperates withgraphical user interface 80 to execute the various routing specificationcommands specified by corresponding drag and drop operations. This isachieved with automated population of MIB tables corresponding to thevarious actual fields necessary to define a routing command. Drag anddrop operations on graphical user interface 80 assist operator 10 indefining video, audio and/or IP data routing events for the system.Defining routing specifications in this way is, therefore,semi-automatic.

[0051] Drag and drop operations on the graphical user interface can beused to perform a variety of related content stream routing functions.These include the ability to drag different levels from the input treeto the output tree. For example, an operator may drag (1) the contentstreams of an entire input port (possibly including plural programs,each of which possibly includes plural components) to an output port;(2) a complete program of an input port to an output port; (3) acomplete program from an input port to a program of an output port; and(4) a component from an input port to an output port. A number of otherdrag and drop features will readily occur to those of ordinary skill inthe art based on the disclosure contained herein. However, it should benoted that this portion of the specification specifically addressescontent stream routing that occurs in the present. The invention,however, also envisions configuration of content stream routing to beautomatically executed at a future time (see, e.g., FIG. 9). Asdescribed in greater detail below, content stream routing processesdescribed immediately below (applicable to execution of present routingcommands) are compatible with, and form a portion of, routing processesfor execution of routing events in the future.

[0052] With primary reference to FIG. 6, operator 10 can specify one ormore present routing events by selecting the graphical objectsrepresenting one or more content streams to be routed to a desiredlocation (e.g., an output port). The content stream could be eithersimple or contain plural components which may or may not be related toone another in one or more ways. For example, the object may represent asingle component content stream, plural content steams that collectivelyconstitute a program, or plural content steams that collectivelyconstitute data streams present on an entire input port. In theillustrative example discussed immediately below, operator 10 drags thecontent streams for an entire port from the input tree to the outputtree and proceeds to edit video and audio components of one program fromthe port.

[0053] Assisted routing in accordance with the invention is preferablyaccomplished with a drag and drop operation of one or more graphicalobjects from the input port window 82 to the output port window 82′ oftree view screen 81. This operation has the effect of capturing, asindicated at 186, configuration data corresponding to the selectedsource of the data stream(s). For example, dragging and dropping thedesired graphical objects enables element manager 22 to automaticallycapture corresponding configuration data for the desired routing eventssuch as input port number and location, output port number and location,content stream PID to be routed and bit rate for the content streams tobe routed. Additionally, information regarding the targeted output port(determined based on where the object is dropped) is also captured (188)by element manager 22 and includes, for example, the location of thetargeted output port. This information enables element manager 22 tocreate default settings and to automatically perform PID aliasing at 186so that there are no data stream conflicts as the various streams arerouted through transport multiplexer 20. The drag & drop editors 93 and94 are then displayed by element manager 22 as indicated at 188. Theoperator can then select the particular component to be edited and, at192, element manager 22 receives the selection and displays a componenteditor (95 for video streams or 95′ for audio streams) with defaultinformation for possible editing. If the default data shown in thecomponent editor 95 is acceptable to the operator, the “OK” button canbe selected to cue the element manager to take further action. Inparticular, closing of the component editor window causes elementmanager 22 to gather the information from the GUI and to request thecreation of various MIB table entries as shown at 194. The TMX executesthe routing events in accordance with the updated MIB's at 196 and theGUI is appropriately updated by the element manager 22 as indicated at198. From the operator's perspective, routing has been specified andperformed simply by dragging and dropping an icon from the input tree toan output tree. In actuality, a variety of routing parameters have beenspecified with the assistance of the system as described in detailabove.

[0054] If operator 10 wishes to modify the default and/or captured data,operator 10 has the ability to edit the information in detail for eachof the components that comprise the content stream. In the exampleshown, operator 10 has selected program 1 (in general, an operator wouldselect some type of graphical object, such as an icon or its associatedtext) shown in editor window 93 and a more detailed editor window 94 isdisplayed, the window showing the constituent components of the selectedprogram. In the case of FIG. 6, program 1 has been selected for editingand it includes one video component and one audio component.

[0055] Graphical user interface 80 preferably has the capability ofidentifying content streams using a variety of graphical objects whichinclude icons, alphanumeric character strings, actual program names,etc. on the various screens. The content stream identification data ispreferably carried within the media stream so that it can beconsistently displayed throughout the graphical user interfaceregardless of which viewing screen is presented to operator 10.Restated, graphical user interface 80 preferably presents a consistentcontent stream name or symbol and can display it throughout theinterface.

[0056] With continuing reference to FIG. 6, selection of the “OK” buttonof window 94 closes the drag and drop window and opens the componenteditor windows corresponding to the selected components as indicated at192. In this case, selection of a component to be edited further resultsin display of one of component editor windows 95 and 95′ where operator10 has the further ability to specify details such as bit rate, targetPID, etc. for any of the components of the desired program. In thiscase, video editor window 95 and audio editor 95′ are displayed forconsideration and possible editing. This feature enables a user to moreeasily allocate bandwidth among the various content streams being routedso that maximum bandwidth utilization can be achieved.

[0057] Upon selection of the “OK” button of one of windows 95 or 95′,the element manager 22 changes the MIB table data in accordance with theedited changes and instructs the TMX to execute the specified routingconfiguration. Configuration manager 46 then sequentially configures thetargeted multiplexer and quantization level processor and enables theinput processor, in that order, as indicated at 196.

[0058] The module activation order, when an output port is enabled, isan important aspect of the present invention. In order to effectivelyexecute a routing event, the targeted multiplexer, quantization levelprocessor and input processor should be activated in the order specifiedto minimize the possibility of the destabilizing the system. Inparticular, configuration manager 46 directs the targeted multiplexer tocollect the designated PIDs and route them to the targeted output.Second, the configuration manager 46 must provide the quantization levelprocessor 64 with the appropriate bit rate and PMT for the contentstream to be routed. Third, configuration manager 46 should instruct theinput processor to send all of the content streams with a particular PIDto the multiplexer. This is preferably accomplished by performing PIDaliasing and then sending the associated data to the multiplexer as alow voltage differential signal.

[0059] As noted above, module activation in an order other than thatdiscussed above may lead to system instability. If, for example, theconfiguration manager attempted to enable the input processor first, themultiplexer may begin to receive a content stream that it does notexpect and this confusion may cause the multiplexer to crash. Similarly,removing a content stream (ceasing to route the stream to the port)should be performed in a predetermined order dictated by configurationmanager 46. In particular, the sequence noted above should be reversed(deactivation of the input processor, deactivation of the QLP and,finally, deactivation of the multiplexer). If, for example, themultiplexer were disabled first, the multiplexer may still receive acontent stream from the input processor and, once again, this conditionmay crash the multiplexer.

[0060] Turning now to FIG. 7, this figure illustrates various systembandwidth utilization viewing capabilities in accordance with onepreferred embodiment of the present invention. As shown therein,operator 10 initiates the view bandwidth utilization feature of theinvention by selecting the bandwidth manager menu item from the upperportion of tree view screen 81. This enables element manager 22 todisplay the bandwidth manager screen at 208 and the TMX begins pollingthe system for bandwidth utilization data and waiting for queries forthis data as shown at 210-212. As indicated more fully in theaccompanying computer program appendix, the MIB tables enable monitoringof MPEG input/output bandwidth utilization information. In particular,the TMXinputPIDtable is used for input rate monitoring per PID. TheTMXoutputPIDtable is used for output rate monitoring per PID.

[0061] In particular, message handler 45 begins polling input processorand output multiplexers for data that is used to update the MIB tables(capturing data from these two sources allows the bandwidth display toshow a comparison between the input bandwidth and output bandwidth) andsends the data as SNMP data to element manager 22, as indicated at 214.Element manager 22 periodically queries the TMX for this information andat 216 displays this data on graphical user interface 80. It thenreturns to continue polling for new bandwidth utilization data at 214.In this way, bandwidth utilization data for all enabled ports iscontinually updated and can be displayed by graphical user interface 80in real-time. Bandwidth data polling preferably ceases when operator 10closes the bandwidth windows 96 and 96′ such as by switching to thechassis or tree view screens. At that point, the PID's for the enabledcontent streams are deleted from the MIB tables.

[0062] Upon receipt of bandwidth utilization data, graphical userinterface 80 displays a bandwidth utilization screen 96. This screenpreferably includes automatically resealing x and y axes and anindividual graphical object for each content stream being routed, eachobject preferably being a bandwidth bar (bars 97, 97′ and 97″ in theexample shown). Each bandwidth bar shown in screen 96 preferablyincludes the following plural attributes: an output bandwidthutilization value 97 a, an input bandwidth utilization value 97 b, amaximum input bandwidth utilization value 97 c and minimum inputbandwidth utilization value 97 d. In practice, changes in the bandwidthutilization are automatically displayed in bandwidth utilization screen96 in real-time.

[0063] Bandwidth utilization screen 96 can include a number ofuser-friendly features to make the graphical user interface even moreintuitive and useful. For example, operator 10 may be provided with theability to select or deselect a legend display shown on the right handportion of bandwidth utilization screen 96. Similarly, operator 10preferably has the ability to select or deselect display of the minimumand maximum bandwidth utilization values. Furthermore, screen 96preferably has the ability to display the same mnemonic identifiers forthe various streams that are used in other screens such as the tree viewscreen. Restated, the graphical user interface preferably reflects aconsistent identifier for each content stream throughout the system.Naturally, other identifiers could be used if desired. These identifiersare preferably sent with the content streams so that they can bedetected and displayed in various screens. As noted above, theidentifiers may be displayed as colored icons and/or alphanumericcharacter strings, etc.

[0064] After viewing bandwidth utilization screen 96, operator 10 mayselect one of the bandwidth bars to dynamically display more detailedinformation about the various components that make up the content streamfor the selected bar. For example, a given program might include onevideo and two audio components. Selecting a bandwidth bar will causedetailed bandwidth utilization window 96′ (with additional informationabout these components) to appear on the screen. This type of selectioncauses element manager 22 to generate a query at 216 which is respondedto by the TMX at 210/212. As shown in window 96′, the program name, thegroup ID and the total bandwidth at the instant that the bandwidth barwas taken are captured and displayed on the screen. In this illustrativeembodiment, the bandwidth bar for program 2 was selected when thebandwidth utilization was about five megabits per second (comparewindows 96 and 96′ of FIG. 7). Additionally, the detailed window breaksthe selected program down into its constituent components. In this casethe program has three constituent parts: IP data 1, video data 1 andaudio data 1.

[0065] The screen 96′ shows even more detailed information for eachcomponent of the program. This information preferably includes abandwidth minima value, a bandwidth maxima value and the instantaneousbandwidth utilization of the constituent components at the instant thedetailed bandwidth utilization window was selected. With joint referenceto screens 96 and 96′, it will be appreciated that the displayedbandwidth utilization of the constituent components sums to thebandwidth utilization of the entire program. Additionally, the sum ofthe minimum values of the constituent components equals the minimumvalue for the program as a whole. Similarly, the maximum value for theentire program equals the sum of the minimum values for each of theconstituent components. Finally, the display shows the packet identifierPID associated with the program.

[0066] Since this aspect of the system displays bandwidth in real-time,the operator will see the bandwidth utilization varying over time. Also,differences in bandwidth utilization at different points in time willreflect the fact that input signals can vary over time on the input sideof the whole system. For example, if an input signal suddenly includesan additional component, the bandwidth display screen will reflect thatchange in real-time.

[0067]FIG. 8 illustrates various event logging and viewing capabilities222 in accordance with one preferred embodiment of the presentinvention. As shown therein, the system has the ability to filter thelog messages displayed on the graphical user interface. Viewing loginformation in accordance with the present invention initially entailsoperator selection of an appropriate log filter level, thereby placingthe system into one of four modes. The filter level is recorded by theelement manager 22 and the number and type of messages displayed in thelog message window 87 of graphical user interface 80 is dictated by thefilter level. The desired log filter level can be selected from the“view” drop down menu item near the top of tree view screen 81 and thenselecting the log messages option. There are preferably four filterlevels: normal status, emergency status, fault status and debug. Indebug mode all of the generated log messages are displayed.

[0068] Upon startup, the TMX chassis 42 the status query task begins topoll the system to thereby generate log messages that are used topopulate the TMXLogPortTable, as shown at 224. The SNMP agent 44 thenwaits to respond to for queries for this information as shown at 226.This log messages can be generated by any one of the various firmwaremodules and element manager 22, GUI 80 and TMX chassis 42 cooperate tocontinually pass log messages in accordance with the previously selectedlog level to the graphical user interface for display in the scrollinglog message window. Additionally, these log messages are stored forpossible retrieval and analysis in the future. Although the log messagespresented to an operator in normal use can be filtered, all log messagesgenerated by the system are preferably stored on the element manager'shost computer. One separate log file is preferably generated for eachday the system is in use and operator 10 has the ability to retrieve andview log messages for any given day in the log file archive screen 98.

[0069] Upon selection of the Log File Menu by operator 10, elementmanager 22 retrieves, displays and stores log files as indicated at 228.This screen is accessed by selecting the “view” menu item near the topof the tree view screen 81 and by then selecting the appropriate option.Upon selection of one of the daily log files from the list of log filesin the archive screen 98, individual log messages from the selected logfile are displayed for viewing on screen 98′ as indicated at 230. Whenreviewing stored log messages, the operator also has the ability tofilter the information by selecting one of the four filter levels asdiscussed above.

[0070]FIG. 9 illustrates various future content stream routingcapabilities 238 in accordance with one preferred embodiment of thepresent invention. Specification of future event(s) is initially drivenby operator action on the tree view screen. In particular, uponinitialization and discovery of the system, the system initially sets upone routing event that spans the current time up to a predetermined timein the future (e.g., two years). This is shown in a time bar 99.Operator 10 can then select time bar 99, as shown in the upper righthand portion of tree view screen 81. The resulting pop-up menu allowsoperator 10 to either modify the displayed current event or to create anew event. In the case of specifying the future routing events, operator10 would create a new event by selecting the create new event option andby specifying start and stop times for the new event. At that point,indicated at 240, another duplicate event (by default) is created byelement manager 22. This information is then sent to the graphical userinterface 80 for display and possible modification as shown at 241. Theparticular editor that is presented to operator 10 depends on what typeof event will be created. In the representative example of FIG. 9, audioand video editors 95 and 95′ are presented. IP data streams could alsobe specified for a future routing event as will readily occur to thoseof ordinary skill based on the teachings contained herein. Once all ofthe various details for the various components of the future event hasbeen completed, this information will be gathered by the element managerat 242 and displayed on screen 81′. As shown on screen 81′, three eventshave been define in the illustrative example of FIG. 9. At 244, elementmanager 22 requests that new entries be added to certain MIB's and TMXchassis 42 executes the configuration changes at 246. Also, elementmanager 22 updates the GUI at 252. This results in a tree view screen81″ that is substantially similar to that of screen 81′, but thatdisplays the routing trees according to the newly executedconfiguration.

[0071] Preferably, none of this future event configuration data isprovided to TMX chassis 42 until shortly prior to the predetermined timefor commencement of the newly defined future event. Then (e.g., about 30seconds prior to the predetermined time), the entire configuration datais sent to TMX chassis 42 for execution. This routing event data isslightly different from that discussed above with respect to FIG. 6, inthat it also includes predetermined time data indicating when the newrouting configuration is to occur. In this way operator 10 can configurethe system to automatically change configuration routing control atfuture predetermined points in time, even in the absence of theoperator. Thus, the system permits automated control of the inventivebroadband media hardware by predetermining routing configurationinformation for extended time periods and enabling automatic executionof such configuration changes.

[0072]FIG. 10 illustrates various IP data encapsulation and insertioncapabilities and processes 260 in accordance with one preferredembodiment of the present invention. As described in greater detailbelow, the present invention enables operator 10 to define and executeIP data encapsulation either manually or semi-automatically.

[0073] In particular, the preferred embodiment of the present inventionprovides operators with the ability to manually enter IP encapsulationconfiguration data element by element or, alternatively, toautomatically enter IP encapsulation configuration data by dragging anddropping graphical objects to and from various locations of the treeview screen 81. Element manager 22 cooperates with graphical userinterface 80 to execute the various routing commands specified bycorresponding drag and drop operations. This is achieved with automatedpopulation of MIB tables corresponding to the various fields necessaryto define a routing command. Drag and drop operations on graphical userinterface 80 assist operator 10 in defining IP encapsulationspecifications for the system in a manner substantially analogous to thesemi-automatic definition of video and audio routing events shown anddescribed with reference to FIG. 6. Those of ordinary skill in the artwill readily appreciate how to extend these concepts to implement dragand drop procedures in order to achieve semi-automated IP dataencapsulation based on the teachings of this specification. Manual, orelement by element, IP data encapsulation techniques are describedimmediately below with respect to FIGS. 10 and 11.

[0074] With primary reference to FIG. 10, operator 10 can specify one ormore IP data encapsulation events 260 by selecting the graphical objectsrepresenting a desired location (e.g., an enabled output port) from atree view screen 262. Operator 10 can then select a particular programinto which encapsulated IP data will be inserted. This enables elementmanager 22 to capture configuration data relating to the targeted outputport and any programs that may be resident thereon at 264. In therepresentative example of FIG. 10, program 1 has been selected forinsertion of an IP data component. Responsive to operator selection ofprogram 1, element manager 22 (at 266) displays a program editor 270 andsends default output port values from the to the graphical userinterface for display. Operator 10 can then enter various valuesrelating to a program into which an IP data component will be insertedwith the assistance of element manager 22 at 272. General and detailedIP data component editors 274 will then be displayed so that a varietyof other parameters can be specified by operator 10. Operator 10 has theability to edit the add/remove/change detailed information in the IPdata components editors for each of the components that comprise thecontent stream. In particular, operator 10 has the ability to specifydetails such as source and destination IP addresses, bit rate, targetPID, etc. for each component of the selected program in the general anddetailed editor windows 274. This feature enables a user to more easilyallocate bandwidth among the various IP data streams being created sothat maximum bandwidth utilization can be achieved. Up to 128 IP datastreams may be simultaneously specified for encapsulation and insertionin this way.

[0075] Upon selection of the “OK” button of one of windows 274, elementmanager 22 executes a number of functions at 276. In particular, elementmanager 22 gathers the edited information from the GUI and requests thatvarious new entries be placed into certain MIB tables with defaultand/or edited data (as shown at 276). Element manager 22 also providesthis information to TMX 42 for execution as shown at 278 of FIG. 10 andin FIG. 11. In particular, at 278, SNMP agent 44 creates the new MIBentries, message handler 45 passes the information to configurationmanager 46 which configures one or more multiplexers and instructs theIP encapsulation module 66 to begin collecting IP data. IP encapsulationmodule 66 then receives IP data from the specified source IP address,encapsulates each IP data packet as one or more MPEG packets, to therebyform MPEG data streams, and sends them to the targeted multiplexer(s).The targeted multiplexer(s) receives the assembled MPEG data packets andstream the MPEG data appropriately. At 280, the element manager updatesthe graphical user interface 80 which displays the updated informationon tree view screen 289. Operator 10 can then view an IP data icon 290that indicates encapsulation and insertion of IP data is occurring.

[0076] The portion of block 278 that performs the IP encapsulationprocess is illustrated in detail in FIG. 11. As shown therein, uponexecution of IP encapsulation process 282, the encapsulation module 66instructs IP data stack (of the operating system running on the hostprocessor) to collect/receive and examine an IP data packet at 292. At293 the module 66 then verifies that the system is prepared to processIP packets (e.g., the target multiplexer(s) has/have been properlyconfigured). The destination IP address for the received IP data packetis then tested for validity at 294. In particular, the destination IPaddress is checked to determine whether it is the broadcast, unicast ormulticast IP address. This is preferably accomplished by verifying thatthe destination address is within the multicast range and that theaddress has been specified for data collection/reception. If the IPaddress indicates that the IP packet is not a multicast packet, thedetermination is made that the IP data packet must be either a broadcastor unicast packet. If so, the data packet is passed through theoperating system (OS) stack in a conventional manner and the processpasses to 296 where it simply waits to receive the next IP data packet.In particular, the preferred OS (VxWorks) employs a standard seven-layerOSI compliant IP stack that processes each broadcast and/or unicastpacket to determine its type and the application that it should processit. Thus, for example, a broadcast packet that is found to be an ARPrequest would be sent to the ARP task for processing.

[0077] Conversely, if the source IP address indicates that the IP datapacket is a multicast IP packet, the packet cannot simply be routedthrough the OS stack because the OS will not recognize the data packetexcept in the unlikely event that it is the intended recipient of thepacket. Thus, if the IP address indicates that the data packet is amulticast packet and if that address is one of the 128 addresses thatelement manage 22 has indicated as being associated with IP data that isto be encapsulated, the IP data will be converted to a different formand routed without going through the IP stack as an IP data packet. Toachieve this, the process first passes to 297 where the IP data packetis fragmented, if necessary, into smaller content components forprocessing. The process then passes to 298 where an MPEG data packet isassembled and sent to the appropriate multiplexer(s). In particular, a 4byte MPEG header that includes the target PID for this packet is createdat 300. Then, at 302 the destination IP address is extracted from the IPdata packet and used to create a 16 byte DSM-CC (Data Storage MediaCommand and Control) header for the first MPEG data packet. Aconventional 4 byte Cyclic Redundancy Code (CRC or CRC32) MPEG suffix ispreferably also included in the last MPEG packet (e.g., following thelast byte of content). Since the system can support output data ineither one of DVB or ASTC data formats, the DSM-CC header also indicateswhich format the output data is in to thereby account for thedifferences between these formats. At 304, up to 168 bytes of contentare added to the MPEG 188 byte packet being created. If this can holdall of the content to be sent, then a CRC is appended after the lastbyte of content. At 308, a determination is made whether any fill datais needed to complete the MPEG packet. If so, process 282 passes to 310where the remainder of the MPEG packet is filled with dummy data. Thisdata is preferably the numerical value of 255 (FF in hexadecimal) and isrepeated until a complete 188 byte MPEG data packet has been formed.With this system of the preferred embodiment, a maximum of one IP datapacket will be inserted into a single MPEG packet. If no fill is needed(or after the packet has been filled), the process passes to 312 wherethe assembled packet is sent to the targeted multiplexer and it ispreferably stored in a FIFO for combination with additional MPEGpackets, if any. Also, the process passes to 314 where is it isdetermined whether or not the received IP data packet has been fullyencapsulated. If so, the process passes to 316 where the multiplexerreceives an indication of how many MPEG data packets it has receivedtogether with an indication that this/these packet(s) should betransmitted. The process 282 then passes to 296 where the IPencapsulation module waits for the next IP data packet to beencapsulated.

[0078] If it is determined at 314 that the IP data packet has not beenfully encapsulated, process 282 passes to 318 where additional contentfrom the IP data packets are assembled into MPEG data packets and sentto the appropriate multiplexer. In particular, process 282 passes from314 to 320 where an MPEG header for the next MPEG data packet iscreated. Up to 184 bytes of IP data and CRC (for the last MPEG packet)are then added to the packet at 322 and, at 326, a determination is madewhether any fill data is needed to complete the MPEG packet. If so,process 282 passes to 328 where the remainder of the MPEG packet isfilled with dummy data. This data is also preferably the numerical valueof 255 (FF in hexadecimal) and is repeated until a complete 188 byteMPEG data packet has been formed. If no fill is needed (or after thepacket has been filled), process 282 passes to 330 where the assembledpacket is sent to the targeted multiplexer and it is preferably storedin a FIFO for combination with all prior and subsequent assembled MPEGpackets, if any. Also, the process passes to 332 where is it isdetermined whether or not the received IP data packet has been fullyencapsulated. If not, steps 320 through 332 are repeated until theentire IP data packet has been encapsulated and, eventually, the processpasses to 316 and 296 as noted immediately below. If so, the multiplexerreceives an indication of how many MPEG data packets it has receivedtogether with an indication that these packets should be transmitted at316. The process then passes to 296 where the IP encapsulation modulewaits for the next multicast IP data packet to be encapsulated. Process282 terminates when operator 10 specifies a different function for thesubject output port or when the time period for the specified event hasexpired. At that point, IP encapsulation module 66 awaits furtherinstructions from configuration manager 46.

[0079] While the present invention has been described in connection withwhat is presently considered to be the most practical and preferredembodiments, it is to be understood that the invention is not limited tothe disclosed embodiments, but is intended to encompass the variousmodifications and equivalent arrangements included within the spirit andscope of the appended claims. With respect to the above description, forexample, it is to be realized that the optimum implementation, functionand manner of operation, assembly and use, are deemed readily apparentto one skilled in the art, and all equivalent relationships to thoseillustrated in the drawings and described in the specification areintended to be encompassed by the appended claims. Therefore, theforegoing is considered to be an illustrative, not exhaustive,description of the principles of the present invention.

What is claimed is:
 1. A control system that uses SNMP to remotely control broadband communications hardware via a network, the communications hardware comprising a plurality of processor boards that perform content stream manipulation and configuration task firmware for configuring and controlling the processor boards, the control system comprising: a user interface for presenting information to a control system operator and for receiving input from the operator; an element manager communicatively linking the user interface to the network, the element manager packaging the operator input as SNMP messages and sending the messages to the SNMP agent via the network, the element manager also receiving SNMP messages from the SNMP agent via the network and providing information contained therein to the user interface for presentation to the operator; and an SNMP agent communicatively linking the configuration task firmware and the network, the SNMP agent comprising means for brokering information exchanged between the element manager and the configuration task firmware.
 2. The control system of claim 1 wherein the SNMP agent translates SNMP messages received from the element manager via the network into a form that can be understood by the configuration task firmware and packages information in to SNMP messages for receipt by the element manager via the network.
 3. The control system of claim 1 wherein the content streams are MPEG 2 data streams, wherein the network is an Ethernet network and wherein the communications hardware is a TMX chassis.
 4. The control system of claim 1 wherein the user interface is a graphical user interface comprising a common browser.
 5. The control system of claim 1 wherein the SNMP agent populates MIB tables with system data received from the configuration task firmware and wherein the element manager reads the system data from the MIB tables and provides it to the user interface for display.
 6. The control system of claim 1 wherein the element manager populates MIB tables with operator input received from the user interface and wherein the SNMP agent reads the operator input from the MIB tables and provides it as instructions to the configuration task firmware.
 7. The control system of claim 1 wherein the element manager runs on a personal computer that is communicatively linked to the network and wherein the element manager has been uploaded to the computer as a java applet via the network during a set-up phase.
 8. A method of remotely controlling broadband communications hardware via a network, the communications hardware comprising a plurality of processor boards for manipulating content streams and configuration task firmware for configuring and controlling the processor boards, the method comprising: receiving content stream control commands from the operator at a first location on the network; packaging the control commands as SNMP messages; sending the SNMP messages across the network to a second location physically remote from the first location; receiving the SNMP messages at the second location; translating the received SNMP messages into control commands that the configuration task firmware can understand; and sending the translated commands to the configuration task firmware for execution.
 9. The method of claim 8 wherein the content streams are MPEG 2 data streams, wherein the network is an Ethernet network and wherein the communications hardware is a TMX chassis.
 10. The method of claim 8 wherein receiving content stream control commands comprises receiving content stream drag and drop commands from a graphical user interface that comprises a browser.
 11. The method of claim 10 wherein packaging the control commands as SNMP messages comprises populating MIB tables with content stream attributes resulting from the drag and drop commands.
 12. The method of claim 10 further comprising polling the communications hardware for system status data; populating MIB tables with the system status data; reading the system status data from the MIB tables; and displaying the system status data on the graphical user interface.
 13. The method of claim 10 further comprising polling the communications hardware for content stream attribute data; populating MIB tables with the content stream attribute data; reading the content stream attribute data from the MIB tables; and displaying the system content stream data on the graphical user interface.
 14. The method of claim 10 further comprising polling the communications processor board attribute data comprising data relating to the identity, structure and operational status of the processor boards; populating MIB tables with the processor board attribute data; reading the processor board attribute data from the MIB tables; and displaying the processor board attribute data on the graphical user interface.
 15. A method of remotely enabling an output port of a TMX chassis via a network, the TMX chassis having a multiplexer, a quantization level processor and an input processor for manipulating content streams passing therethrough to the output port, the method comprising: receiving a port enable command from an operator at a first location on the network; sending the port enable command across the network to the TMX chassis at a second location physically remote from the first location; and responsive to receipt of the port enable command, activating the targeted multiplexer first, activating the quantization level processor second; and activating the input processor third to thereby permit a content stream to pass to the output port. 